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Abstract 


This document defines new Dynamic Host Configuration Protocol (DHCPv4 
and DHCPv6) options that contain a list of IP addresses anda list of 
domain names that can be mapped to servers providing IEEE 802.21 type 


of Mobility Service (MoS) (see RFC 5677). These Mobility Services 
are used to assist a mobile node (MN) in handover preparation 
(network discovery) and handover decision (network selection). The 


services addressed in this document are the Media Independent 
Handover Services defined in IEEE 802.21. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 
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1. Introduction 


TEEE 802.21 [IEEE802.21] defines three distinct service types to 
facilitate link layer handovers across heterogeneous technologies: 


a) Information Services (IS) 
IS provides a unified framework to the higher-layer entities 
across the heterogeneous network environment to facilitate 
discovery and selection of multiple types of networks existing 
within a geographical area. The objective is to help the higher- 
layer mobility protocols acquire a global view of heterogeneous 
networks and perform seamless handover across these networks. 


b) Event Services (ES) 
Events may indicate changes in state and transmission behavior of 
the physical, data link, and logical link layers, or predict state 
changes of these layers. The Event Service may also be used to 
indicate management actions or command status on the part of the 
network or some management entity. 


c) Command Services (CS) 
The command service enables higher layers to control the physical, 
data link, and logical link layers. The higher layers may control 
the reconfiguration or selection of an appropriate link through a 
set of handover commands. 


Bajko & Das Standards Track [Page 2] 


RFC 5678 Mobility Services for DCHP Options December 2009 


In IEEE terminology, these services are called Media Independent 
Handover (MIH) services. While these services may be co-located, the 
different pattern and type of information they provide do not 
necessitate the co-location. 


A mobile node (MN) may make use of any of these MIH service types 
separately or any combination of them [RFC5677]. In practice, a 
Mobility Server may not necessarily host all three of these MIH 
services together; thus, there is a need to discover the MIH service 
types separately. 


This document defines new DHCPv4 and DHCPv6 options and sub-options 
called the MoS IP Address and Domain Name List Options, which allow 
the MN to locate a Mobility Server that hosts the desired service 
type (i.e., IS, ES, or CS) as defined in [IEEE802.21]. Apart from 
manual configuration, this is one of the possible solutions for 
locating a server providing Mobility Services. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.2. Terminology 


Mobility Services: a set of services provided by the network to 
mobile nodes to facilitate handover preparation and handover 
decision. In this document, Mobility Services refer to the services 
defined in IEEE 802.21 specifications [IEEE802.21] 


Mobility Server: a network node providing Mobility Services. 
MIH: Media Independent Handover, as defined in [IEEE802.21]. 


MIH Service: IS, ES, or CS type of service, as defined in 
[IEEE802.21]. 


2. MoS IPv4 Address Option for DHCPv4 


This section describes the MoS IPv4 Address Option for DHCPv4. 
Whether the MN receives a MoS address from the local or home network 
will depend on the actual network deployment [RFC5677]. The MoS IPv4 
Address Option begins with an option code followed by a length and 
sub-options. The value of the length octet does not include itself 
or the option code. The option layout is depicted below: 
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Oe AE 4 5756 Ff 85795508 23 e456. 8 Oe OAL 29 Si- An Bs 16 it Be "98 Oi 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Option Code | Length | 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++HH 

Sub-Option 1 | 


— + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+ +++ 
Sub-Option n | 


—+. 


. —+e 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Option Code 


OPTION-IPv4_Address-MoS (139) 


l 
m 


byte 
Length 


An 8-bit field indicating the length of the option excluding 
the ’Option Code’ and the ‘Length’ fields 


Sub-options 
A series of DHCPv4 sub-options 
When the total length of a MoS IPv4 Address Option exceeds 254 
octets, the procedure outlined in [RFC3396] MUST be employed to split 


the option into multiple, smaller options. 


A sub-option begins with a sub-option code followed by a length and 
one or more IPv4 addresses. The sub-option layout is depicted below: 


OT EAS E A o E o e a O D2 34: E E E: 9 Oy 2 BA 6. T A a OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Sub-opt Code | Length | TP. Address. o- os -o a . 
Fatt ata tata ta tata tantra ata tata ttt tata tata tatatatatatatatatat 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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The sub-option codes are summarized below. 


prine poe + 
| Sub-opt | Service | 
| Code | Name | 
+ + + 
| 41 | ts | 
+-------------- 4+--------------- + 
| 2 | cs | 
ae ae ae eae a + 
| 3 | ES | 
HHS SSeS Seo se Posse sta Sess + 


If the length is followed by a list of IPv4 addresses indicating 
appropriate MIH servers available to the MN for a requested option, 
servers MUST be listed in order of preference and the client should 
process them in decreasing order of preference. In the case that 
there is no MIH server available, the length is set to 0; otherwise, 
it is a multiple of 4. 


The sub-option has the following format: 


Code Len IPv4 Address 1 IPv4 Address 2 
+----- 4+---+---+4----+----4+----+----4+----+4--- 
}1..3 | n [a1 | a2 |a3 | a4 | at | 
+----- 4+---+---4----+----4+----+----- +----+-- 


3. MoS Domain Name List Option for DHCPv4 


This section describes the MoS Domain Name List Option for DHCPv4. 
The general format of this option is depicted below: 


0123456789012345678°9012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Option Code | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
Sub-Option 1 | 


— + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+ +++ 
Sub-Option n | 


— + »• 


. —+e 


+-4+-4-4-4-4-4-4-4-4-4+-4+-4-4+-4+-4-4+-4+-4-4+-4-4+-4-4-4-4-4-4-4-4-4-4-4 


Bajko & Das Standards Track [Page 5] 


RFC 5678 Mobility Services for DCHP Options December 2009 


Option Code 
OPTION-IPv4_FQDN-MosS (140) - 1 byte 
Length 


An 8-bit field indicating the length of the option excluding 
the ’Option Code’ and the ‘Length’ fields 


Sub-options 
A series of DHCPv4 sub-options. 
When the total length of a MoS Domain Name List Option exceeds 254 
octets, the procedure outlined in [RFC3396] MUST be employed to split 
the option into multiple, smaller options. 
A sub-option begins with a sub-option code followed by a length and 
one or more Fully Qualified Domain Names (FQDNs). The sub-option 
layout is depicted below: 
012345678901234567890123456789021 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4-4-4+-4-4-4 
| Sub-opt Code | Length | FQDN(s) ©... 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4-4+-4-4-4 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The sub-option codes are summarized below. 


Farei 4+--------------- + 
| Sub-opt | Service | 
| Code | Name | 
+ + + 
| 1 | IS | 
A N EE + 
| 2 | cs | 
t-------------- 4+--------------- + 
| 3 | ES | 
+-------------- 4+--------------- + 


Thus, the sub-option for this encoding has the following format: 


Code Len DNS name of Mobility Server 
+----- +----+----+----- +----- +----- +----- +-- 
bBo | cae sT ergs TS sssi ssia ee 
+----- +----+----+----- +----- +----- +----- +-- 
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The sub-option begins with a sub-option code followed by a length and 
a sequence of labels that are encoded according to Section 8 of 
[RFC3315]. 


The sub-option MAY contain multiple domain names, but these should 
refer to the NAPTR records of different providers, rather than 
different A records within the same provider. That is, the use of 
multiple domain names is not meant to replace NAPTR and SRV records, 
but rather to allow a single DHCP server to indicate MIH servers 
operated by multiple providers. 


The client MUST try the records in the order listed, applying the 
mechanism described in [RFC5679] for each. The client only resolves 
the subsequent domain names if attempts to contact the first one 
failed or yielded no common transport protocols between the MN and 
the server. 


As an example, consider the case where the server wants to offer two 
MIH IS servers, "example.com" and "example.net". These would be 
encoded as follows: 


pee SS Sfpees +See fee ates] feseates=peseSpeSsefesestee= tees tesa=fesetes=p 
[aes |26 | 7 (te |z? | aiim [pi Nr Fet] 3 (Eero? Zm] 0 | 
eS ee ee L ee ee ee eee ee ee eee 
CA a toies Goel eas oir gee aches sae E L 
| 7 [Pet px | Par | tm? pe yare | 3 [rat [rere] 0 | 
a a ot cea Gromit a ara edn ocean eel oceelackeats onli: 


4. MoS IPv6 Address Option for DHCPv6 


This section describes the MoS IPv6 Address Option for DHCPv6. 
Whether the MN receives a MoS address from the local or home network 
will depend on the actual network deployment [RFC5677]. The MoS 
Discovery Option begins with an option code followed by a length and 
sub-options. The value of the length octet does not include itself 
or the option code. The option layout is depicted below: 
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Sub-Option 1 | 


Od 2°38: 4526. Po 898 O a 2), BA So Or P78 9F OCD: 2 B45. 6s E: 2950 eT 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++H+ 
| Option Code | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| 


$ototatatatatitototitatotitatatatatitotititititititatatatitottet 
| Sub-Option n | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


E E E S EER E E E EE he ah Ge pee a E 
Option Code 
OPTION-IPv6_Address-MoS (54) - 2 bytes 
Length 


A 16-bit field indicating the length of the option excluding 
the ’Option Code’ and the ’Length’ fields. 


Sub-options 
A series of DHCPv6 sub-options 


The sub-options follow the same format (except the Sub-opt Code and 
Length value) as described in Section 2. The value of the Sub-opt 

Code and Length is 2 octets, and the Length does not include itself 
or the Sub-opt Code field. The sub-option layout is depicted below: 


Ow. 263-49 46 7) 8.900 1-2-3049 6. 78 9) 0 23 A 6 T 89 0. I 
$i4-4-4-4-t-t-t-t- t+ 4-4-4 ttt ttt 4-4 Fi tatititit-4-4-4-4-4 
| sub-opt Code | Length | 
$-4-4-4-4-4-t-F-$-4-4-4-4-4-t-t ttt 4-4 4-t- ttt t-+-4-4-4-4-4+ 
| IP Address | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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The sub-option codes are summarized below. 


+---------------- +--------------- + 
| Sub-opt Code | Service Name | 
+ + + 
[a we | Is | 
+---------------- +--------------—- + 
| 2 | cs | 
+---------------- +--------------- + 
| 3 | ES | 
+---------------- +--------------- + 


If the length is followed by a list of IPv6 addresses indicating 
appropriate MIH servers available to the MN for a requested option, 
servers MUST be listed in order of preference and the client should 


process them in decreasing order of preference. In the case where 
there is no MIH server available, the length is set to 0; otherwise, 
it is a multiple of 16. 


5. MoS Domain Name List Option for DHCPv6 


This section describes the MoS Domain List Option for DHCPv6. The 
general format of this option is depicted below: 


OF REEE a rh BOF OD BPS E 8S OD 2) 3) Al 1 65 “Po B 90: cL 
-+-+-+-+-+-+-+-+-+-+-+ ++ 
Option Code | Length | 
-+-+-+-+-+-+-+-+-+-+-+ +++ 
Sub-Option 1 | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


— + »• 


-+-+-+-+-+-+-+-+-+-+-+ +++ 
Sub-Option n | 


. — + >œ 


VEE E E E E E E E E E E E E EEE 
Option Code 
OPTION-IPv6_FQDN-MoS (55) - 2 bytes 
Length 


A 16-bit field indicating the length of the option excluding 
the ’Option Code’ and the ‘Length’ fields 
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Sub-options 
A series of DHCPv6 sub-options 


The sub-options follow the same format (except the Sub-opt Code and 
Length value) as described in Section 3. The value of the Sub-opt 

Code and Length is 2 octets, and the Length does not include itself 
or the Sub-opt Code field. The sub-option layout is depicted below: 


On Le 8) Ae STOT BATO D234. pa 6 PB 96.0, 23. A926 FB. '9-0) A. 
$otatatatatatititototitotitatatatatitototititititatitatatatototet 
| sub-opt Code | Length | 
$otatatatatatitotototitotitatatatatititotititititatatatatitototot 
| FODN (s) | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The sub-option codes are summarized below. 


+---------------- +--------------- + 
| Sub-opt Code | Service Name | 
+ + + 
hl | IS | 
+---------------- +--------------- + 
i.e | cs | 
+---------------- +--------------- + 
| 3 | ES | 
+---------------- +--------------- + 


The semantics and content of the DHCPv6 encoding of this option are 
exactly the same as the encoding described in Section 3, except the 
Option Code and Length value. 


6. Option Usage 
6.1. Usage of MoS Options for DHCPv4 


The requesting and sending of the proposed DHCPv4 options follow the 
rules for DHCP options in [RFC2131]. 


6.1.1. Mobile Node Behavior 


The mobile node may perform a MoS discovery either during initial 
association with a network or when the mobility service is required. 
It may also try to perform the MoS discovery when it lacks the 
network information for MoS or needs to change the MoS for some 
reasons, for instance, to recover from the single point of failure of 
the existing MoS. 
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In order to discover the IP address or FQDN of a MoS, the mobile node 
(DHCP client) MUST include either a MoS IPv4 Address Option or a MoS 
Domain Name List Option in the Parameter Request List (PRL) in the 
respective DHCP messages as defined in [RFC2131]. 


The client MAY include a MoS IPv4 Address Option or a MoS Domain Name 
List Option that includes one or more sub-option(s) with the Sub-opt 
Code or Codes that represent the service(s) the mobile node is 
interested in. However, a client SHOULD be prepared to accept a 
response from a server that includes other sub-option(s) or does not 
include the requested sub-option(s). 


6.1.2. DHCP Server Behavior 


When the DHCP server receives either a MoS IPv4 Address Option or a 
MoS Domain Name List Option in the PRL, the DHCP server MUST include 
the option in its response message as defined in [RFC2131]. 


A server MAY use the sub-options in the received MoS IPv4 Address 

Option or MoS Domain Name List Option from the client’s message to 
restrict its response to the client requested sub-options. In the 
case when the server cannot find any Mobility Server satisfying a 

requested sub-option, the server SHOULD return the MoS Option with 
that sub-option and the length of the sub-option set to 0. 


6.2. Usage of MoS Options for DHCPv6 


The requesting and sending of the proposed DHCPv6 options follow the 
rules for DHCP options in [RFC3315]. 


6.2.1. Mobile Node Behavior 


The mobile node may perform the MoS discovery either during initial 
association with a network or when the mobility service is required. 
It may also try to perform the MoS discovery when it lacks the 
network information for MoS or needs to change the MoS for some 
reasons, for instance, to recover from the single point of failure of 
the existing MoS. 


In order to discover the IP address or FQDN of a MoS, the mobile node 
(DHCP client) MUST include either a MoS IPv6é Address Option or a MoS 
Domain Name List Option in the Option Request Option (ORO) in the 
respective DHCP messages as defined in [RFC3315]. 


The client MAY include a MoS IPv6 Address Option or a MoS Domain Name 


List Option that includes one or more sub-option(s) with the Sub-opt 
Code or Codes that represent the service(s) the mobile node is 
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interested in. However, a client SHOULD be prepared to accept a 
response from a server that includes other sub-option(s) or does not 
include the requested sub-option(s). 


6.2.2. DHCP Server Behavior 


When the DHCP server receives either a MoS IPv6 Address Option or a 
MoS Domain Name List Option in the ORO, the DHCP server MUST include 
the option in its response message as defined in [RFC3315]. 


A server MAY use the sub-options in the received MoS IPv6 Address 

Option or MoS Domain Name List Option from the client’s message to 
restrict its response to the client-requested sub-options. In the 
case when the server cannot find any Mobility Server satisfying a 

requested sub-option, the server SHOULD return the MoS Option with 
that sub-option and the length of the sub-option set to 0. 


7. Security Considerations 


The security considerations in [RFC2131] apply. If an adversary 
manages to modify the response from a DHCP server or insert its own 
response, an MN could be led to contact a rogue Mobility Server, 
possibly one that then would provide wrong information, event or 
command for handover. 


It is recommended to use either DHCP authentication option described 
in [RFC3118] where available. This will also protect the denial-of- 
service attacks to DHCP servers. [RFC3118] provides mechanisms for 

both entity authentication and message authentication. 


In deployments where DHCP authentication is not available, lower- 
layer security services may be sufficient to protect DHCP messages. 


Regarding domain name resolution, it is recommended to consider the 
usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational 
Practices [RFC4641]. Security considerations described in [RFC5679] 
also apply. 

8. IANA Considerations 


This document defines two new DHCPv4 options as described in Sections 
2 and 3. 


MoS IPv4 Address Option for DHCPv4 (OPTION-IPv4_Address-MoS) 139 


MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS) 140 
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This document creates a new registry for the Sub-Option fields in the 
MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service 
Type" (Section 2 and 3). 


Is 1 
CS 2 
ES 3 


The values ’0’ and ’255’ are reserved. Values ’1’ through ’3’ are 
allocated as above, and the rest are available for allocation. New 
values can be allocated via Standards Action as defined in [RFC5226]. 


This document also defines two DHCPv6 options as described in 
Sections 4 and 5. 


MoS IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-MosS) 54 
MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS) 55 


This document creates a new registry for the sub-option field in the 
MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 IPv6 


Service Type" (Sections 4 and 5). 
Is 1 
CS 2 
ES 3 


The values ’0’ and '’65535’ are reserved. Values ‘1’ through ’3’ are 
allocated as above, and the rest are available for allocation. New 
values can be allocated via Standards Action as defined in [RFC5226]. 
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